Hi, developers of Voxblox, are there really some large bumps on the ground or just noisy data?

And what's the localization approach being used in this scenario? THX!

Hahaha. Excellent question. These are apriltags on posts:

What's still not reconstructed is the thin post between the tags, working on a weighting scheme to allow better reconstructions of very thin objects.
What was used in this scenario is just rovio, open-loop: https://github.com/ethz-asl/rovio/ (with this PR because we look at the props + frame of the drone: ethz-asl/rovio#206). Camera setup is a Pointgrey Blackfly camera, triggered by a pixhawk and using an ADIS448 IMU hooked up to the pixhawk. LIDAR is Ouster OS1 64-beam.
Hope that helps!

IMPORTANT USAGE NOTE: this tuning is for static environments. The sparsity_compensation_factor trades off between confidence of clear rays vs. voxels in the truncation distance (a factor of 10 = 10x more confident in occupied voxels than in free voxels). This will mean in dynamic environments, it will take longer to clear space for occupied objects. Please tune appropriately for your application. ;)

@helenol THX. Is that railing really considered very thin? I remember that we can construct this kind of object very easily while using xtion with voxblox. Ha, the mask approach is brilliant, though we always implement rovio/rovioli with the base in the view on our wheeled robot and the VIO still works quite well. I also notice that you guys used orbslam with voxblox to reconstruct the machine hall scene as the output example. From my personal experience, ASL housemade VIO(rovioli) is much more robust/stable then orbslam (I think the only pro for orbslam might be it can directly leverage RGBD data which can get rid of some scaling problem when the VO system move in a constant speed without the help from other sensors), so why did you prefer orbslam over rovioli when you implemented that example?
Since you mentioned space clearing in dynamic environments, we had an issue related to it a long time ago. We found that with max_weight at the default value (10000.0), when the RGBD sensor was still, voxblox would clear the object that already removed in the scene very slowly if the object was seen in the scene for a half minute and placed 4 meters away before it was removed. We must set max_weight to a very small value to guarantee everything is simultaneously cleared in the voxblox when it was physically removed from the view. So I am wondering if you guys also use the default max_weight value in the dynamic environment?

@bx237
Re: thin post. Depends on voxel size and sensor resolution, right? We're using 10 cm voxels for being able to plan in the map. Again everything is just down to tuning per application...

Re: ORBSlam we needed a system with online loop-closures for this paper: https://arxiv.org/pdf/1710.07242.pdf
We use ROVIO for live operation on the drones for the same reasons you described. Much more robust, much less computational need. We'll have some more new work using the c-blox approach without ORBslam coming out soon. ;)

Re: rovio masking: I would encourage you to try out the mask if you see any robot structure in your FoV, my very limited evening of experience seems to indicate it decreases drift and increases robustness (rovio looking at props in a dusty, dark, crappy mine with masking seems to work better than rovio looking at tiny bits of the drone's arms in a nice, feature-rich well-lit environment without masking).

Re: dynamic environments. Most of our applications are in static or "slowly dynamic" environments, where we assume things change slowly or not at all. So, i.e., filtering the safety pilot who is constantly moving around is important to us, but we do not expect large changes in structure like what you described to take place. In these cases yes a much smaller max_weight is much more appropriate.

@helenol Thank you for the detailed reply. I will try the mask approach. You guys are making marvelous things. Keep it up!